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Abstract 

We design and implement a library for adding backtracking com¬ 
putations to any Haskell monad. Inspired by logic programming, 
our library provides, in addition to the operations required by the 
MonadPlus interface, constructs for fair disjunctions, fair conjunc¬ 
tions, conditionals, pruning, and an expressive top-level interface. 
Implementing these additional constructs is easy in models of 
backtracking based on streams, but not known to be possible in 
continuation-based models. We show that all these additional con¬ 
structs can be generically and monadically realized using a single 
primitive msplit. We present two implementations of the library: 
one using success and failure continuations; and the other using 
control operators for manipulating delimited continuations. 

Categories and Subject Descriptors D.1.1 [Programming Tech¬ 
niques ]: Applicative (Functional) Programming; D.1.6 [Program¬ 
ming Techniques ]: Logic Programming; D.3.3 [Programming 
Languages ]: Language Constructs and Features—Control struc¬ 
tures; F.3.3 [Logics and Meanings of Programs]: Studies of Pro¬ 
gram Constructs—Control primitives 

General Terms Languages 

Keywords continuations, control delimiters, Haskell, logic pro¬ 
gramming, Prolog, streams. 

1. Introduction 

One of the benefits of monadic programming is that it gener¬ 
alises over all computational side effects or notions of computa¬ 
tion [16, 17], thus supporting custom evaluation modes like non¬ 
determinism and backtracking [29, 30]. Using monads to express 
non-determinism and backtracking is far from a theoretical curios¬ 
ity. Haskell’s MonadPlus type class, which defines a backtracking 
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monad interface, has found many practical applications [20], rang¬ 
ing from those envisioned for McCarthy’s amb operator [15] and 
its descendents [25], to transactions [28], pattern combinators [27], 
and failure handling [21]. 

In a functional pearl [11], Hinze describes backtracking monad 
transformers that support non-deterministic choice and a Prolog¬ 
like cut with delimited extent. Hinze aimed to systematically de¬ 
rive his monad transformers in two ways, yielding a term imple¬ 
mentation and a (more efficient) context-passing implementation. 
The most basic backtracking operations, failure and non-determin- 
istic choice, are indeed systematically derived from their specifi¬ 
cations. But when it came to cut, creative insight was still needed. 
Furthermore, the resulting term implementation is no longer based 
on a free term algebra, and the corresponding context-passing im¬ 
plementation performs pattern-matching on the context. As Hinze 
notes [11], this context-passing implementation differs from a tra¬ 
ditional continuation-passing-style (CPS) implementation that han¬ 
dles continuations abstractly. In other words, the implementation is 
not directly amenable to a direct-style implementation using con¬ 
trol operators. 

Most existing backtracking monad transformers, including the 
ones presented by Hinze, suffer from three deficiencies in practical 
use; unfairness, confounding negation with pruning, and a limited 
ability to collect and operate on the final answers of a non-deter- 
ministic computation. First, the straightforward depth-first search 
performed by most implementations of MonadPlus is not fair: a 
non-deterministic choice between two alternatives tries every solu¬ 
tion from the first alternative before any solution from the second 
alternative. When the first alternative offers an infinite number of 
solutions, the second alternative is never tried, making the search 
incomplete. Indeed, as our examples in Section 3 show, fair back¬ 
tracking helps more logic programs terminate. Naturally, the im¬ 
portance of fairness has been recognised before (e.g., by Seres and 
Spivey [23, 26], who also present a simple term implementation 
based on streams). Our contribution in this regard is to implement 
fair disjunctions and conjunctions in monad transformers and using 
control operators and continuations. 

The second deficiency in many existing backtracking monads 
is the adoption of Prolog’s cut, which confounds negation with 
pruning. Theoretically speaking, each of negation and pruning in¬ 
dependently makes logic programming languages more expres¬ 
sive [9, 18], Pruning also allows an implementation to reclaim stor- 



age and thus run some logic programs in constant space [18]. But 
negation does not necessarily imply pruning. In fact, Naish [18] 
points out that Prolog’s cut is best understood as a combination 
of two operators: a logical if-then-else (also known as soft-cut, or 
negation as failure) and don’t-care non-determinism (also known as 
once). Thus we separate the implementation and expressive power 
of these two operators and eschew the overloaded cut in our library. 

The third practical deficiency is the often-forgotten top-level in¬ 
terface: how to run and interact with a computation that may re¬ 
turn an infinite number of answers? The most common solution is 
to provide a stream that can be consumed or processed at the top- 
level as desired. But in the case of monad transformers, this solution 
only works if the base monad is non-strict (such as Haskell’s lazy 
list monad and LazyST). In the case where the base monad is strict, 
the evaluation may diverge by forcing the evaluation of the entire 
stream, even if we only desire one answer. A less common solu¬ 
tion is to explicitly include in the top-level request the maximum 
number of answers to return. Such an interface is trivial to imple¬ 
ment if the backtracking effect is internally realized using streams, 
but apparently impossible if the effect is internally realized using 
continuations or control operators. Indeed, no existing system that 
uses continuations seems to provide such an interface. We however 
show how to uniformly implement this interface in our model. 

To summarise our contributions, we implement a backtracking 
monad transformer with fair disjunctions, fair conjunctions, soft- 
cut, once, and an expressive top-level interface. In addition to 
discussing the standard stream-based implementation, we show two 
technically-challenging implementations, one based on CPS and 
the other based on a “control channel”: 

1. The CPS implementation uses a success continuation alongside 
a failure continuation. It is efficient in two ways: 

(a) It does not pattern-match on these continuations but only 
invokes them. 

(b) It is the result of CPS-transforming a direct-style imple¬ 
mentation that runs deterministic code “at full speed”—that 
is, without any interpretive overhead—insofar as the base 
monad to which the monad transformer is applied runs at 
full speed with mutable state and delimited control. 

2. Underscoring this last point, the control-channel implementa¬ 
tion uses fully-polymorphic multiprompt delimited continua¬ 
tions [7]. Thus our monad transformer factors through delim¬ 
ited control. This implementation can be extended with more 
sophisticated search strategies that handle left recursion with¬ 
out tabling, and that avoid pitfalls that make depth-first search 
incomplete and breadth-first search impractical. We omit such 
extensions here and refer the interested reader to the Kanren 
project [10], 

We achieve fair disjunctions and conjunctions, negation, prun¬ 
ing, and an expressive top-level interface across these two imple¬ 
mentations by requiring of them a single operation beyond the 
MonadPlus interface, called msplit. Roughly, msplit means to look 
ahead for one solution. It has the signature: 

msplit :: (Monad m,LogicT t, MonadPlus (t m )) => 
t m a —>t m (Maybe (a, t m a)) 

where m is the underlying monad that provides arbitrary effects, 
and t is the monad transformer designed and implemented in this 
paper. Intuitively, msplit computes the first solution (if any) and 
suspends the rest of the computation. Although it seems that msplit 
simply de-constructs a list or stream, it is not so easy to implement 
when t m a is not a stream (indeed, not even a recursive type), as 
is the case for our CPS and control-channel implementations. The 
msplit operation does however let us treat the transformed monad as 


a stream, even when it is not. In particular, we can observe not just 
the first solution from a backtracking computation but an arbitrary 
number of solutions, even using an implementation not based on 
streams. 

This paper is a literate Haskell 98 program, except that we 
need the commonly implemented extension of rank-2 polymor¬ 
phism [19] for the control operators of Section 5.2. All the code 
described in the paper is available at http: //pobox. com/~oleg/ 
ftp/packages/LogicT. tar. gz under the MIT License. 

2. Basic Backtracking Computations: MonadPlus 

The MonadPlus interface provides two primitives, mzero and 
mplus, for expressing backtracking computations. The command 
mplus introduces a choice junction, and mzero denotes failure: 
class Monad m => MonadPlus m where 

mplus :: m a —» m a —> m a 

The precise set of laws that a MonadPlus implementation should 
satisfy is not agreed upon [1], but there is reasonable agreement on 
the following laws [11]. (We discuss what kind of equivalence - 
means in Section 3.4.) 


Definition 2.1 (Laws for MonadPlus). 


mplus a mzero 
mplus mzero a 
mplus a {mplus b c) 

{mplus a b) »= k 


mplus {mplus ab) c 
mplus {a »= k) (b »= k) 


The intuition behind these laws is that mplus is a disjunction of 
goals and »= is a conjunction of goals. The conjunction evaluates 
the goals from left-to-right and is not symmetric. 

Using these operations, we may write some simple examples: 
h,t 2 ,t 3 :: MonadPlus m =s mint 


f 2 = return 10 ‘mplus‘ return 20 ‘mplus’ return 30 
t 3 = msum {map return [ 10,20,30]) 

The first example represents a choice that leads to failure. The 
second and third examples are identical, using a library definition of 
msum: they both represent a computation with three choices, each 
succeeding with a different integer. 

For simple examples like these, the built-in list monad is an 
adequate implementation of the MonadPlus interface. The empty 
list denotes failure; a singleton list denotes a deterministic com¬ 
putation; and a list with more than one element denotes multiple 
successful results returned by multiple choices. To run such exam¬ 
ples, we can trivially convert the answers generated by the multiple 
choices into a stream of answers: 
runList :: [a] —» [a] 
runList = id 

Indeed, runList t\ returns the empty list, and runList h and 
runList t 3 both return the list [ 10,20,30]. 

The list monad imposes an interpretive overhead on even deter¬ 
ministic computations, because it constructs and destructs single- 
ton lists over and over again. Moreover, it takes quadratic time to 
enumerate all the solutions of a program like [11]: 

( ... {return 1 ‘mplus’ return 2) ‘mplus’ ... return n) 

Other, more efficient implementations of backtracking have been 
proposed using the two-continuation model [8] and delimited con¬ 
trol operators [5]. We revisit the various implementations of back¬ 
tracking after we enrich the interface of MonadPlus with additional 



operators that are considered useful for realistic programming ap¬ 
plications. 

3. A More Expressive Interface 

In this section, we extend the bare-bones MonadPlus interface with 
four combinators, for fair disjunctions, fair conjunctions, condi¬ 
tionals, and pruning. But first, let us generalise the runList function 
to monads other than the list monad. 

3.1 Running Computations 

To run commands in a backtracking monad, we use a function runL, 
which is discussed in detail in Section 6. For now it suffices to think 
of runL as having the following type: 
runL :: Maybe Int —> La —> [a] 

where L is the backtracking monad in question. When the first 
argument to runL is Nothing, all answers are produced. But when 
the first argument to runL is Just n, at most n answers are produced. 

3.2 Interleaving (Fair Disjunction) 

Many realistic logic programs make a potentially infinite number 
of non-deterministic choices. For example, the computation: 
odds :: MonadPlus m => m Int 

odds = (return 1) ‘mplus‘ (odds »= La —> return (2 + a )) 
succeeds an infinite number of times. Running runL (Just 5) odds 
produces the list [ 1,3,5,7,9]. 

Computations that succeed an infinite number of times can¬ 
not be combined naively with other computations. For example, 
odds ‘mplus‘ f 3 never considers t 3 and thus the execution of the pro- 

runL (Just 1) (do jc <— odds ‘mplus‘ t 3 

if even x then return x else mzero ) 

diverges without ever succeeding. In this case, however, the three 
answers 10, 20, and 30 that could be returned by f 3 if it were 
executed are all even. In other words, the entire computation could 
diverge due to the infinite number of successes with odd numbers 
generated by odds. 

More abstractly, in addition to the laws in Definition 2.1, mplus 
satisfies an extra law: 

m i ‘mplus‘ m — mi 

whenever mi is a computation that can backtrack arbitrarily many 
times. This law is undesirable as it compromises completeness. 
This undesirable property is a direct consequence of the associa¬ 
tivity of mplus: it holds up to finite observations in any implemen¬ 
tation of MonadPlus which satisfies the laws in Definition 2.1 (in¬ 
cluding the specific List monad). 

It would thus be useful to have a new primitive interleave such 
that: 

runL (Just 10) (odds ‘ interleave ‘ f 3 ) 
would produce [1,10,3,20,5,30,7,9,11,13], This would allow: 
runL (Just 1) (do jc <— odds ‘interleave‘ f 3 

if even x then return x else mzero ) 
to succeed with the answer 10. 


1 For the code examples in this section, it is tempting to write ... $ do _ 

but that would not work with our control-channel implementation of back¬ 
tracking in Section 5.2, because the type of the computation passed to that 
runL must be polymorphic, which the “predicative” rank-2 polymorphism 
in Haskell [19] does not allow in an argument to $. 


3.3 Fair Conjunction 

The distributivity law from Definition 2.1 states that: 

{mplus a b) »= k - mplus (a »= k ) (b »= k) 

If a»=k is a computation that can backtrack arbitrarily many times, 
then mplus never considers b »= k, which means that in this case 
the following two expressions become equivalent: 

{mplus a b) »= k — a »= k 

Thus the unfairness of disjunction (mplus) causes the unfairness of 
conjunction (»=). For example, the program: 

let oddsPlus n = odds »= Aa —> return {a + n) 
in runL (Just 1) 

(do x <— (return 0 ‘mplus‘ return 1) »= oddsPlus 
if even x then return x else mzero) 

diverges, even though there exists an infinite number of answers 
from return 1 »= oddsPlus. Therefore, in addition to a fair mplus 
we need a fair »=, which we denote with »-. Using such a 
combinator, the program: 

let oddsPlus n = odds »= Aa —> return {a + n) 
in runL (Just 1) 

(do x <— (return 0 ‘mplus‘ return 1) »— oddsPlus 
if even x then return x else mzero) 
succeeds with the answer 2. 

3.4 Laws of interleave and »— 

By design, interleave and »— are fair analogues of mplus and »=. 
In order to state the analogues for the laws in Definition 2.1, it 
is helpful to realize that every non-deterministic computation can 
be represented as either mzero or return a ‘mplus‘ mr for some a 

Definition 3.1 (Laws for Fair MonadPlus). 
interleave mzero m 
interleave (return a ‘mplus‘ mi) m2 
return a ‘mplus‘ (interleave m2 mi) 

(mplus (return a) m) »- k 
interleave (k a) (m »- k) 

There are no explicit laws for computations of the form: 
interleave m mzero 

but we can reason about such computations as follows. Either m is 
mzero and hence the entire expression is equivalent to mzero, or m 
can be represented as return a ‘mplus‘ mr and then: 

interleave m mzero - 

interleave (return a ‘mplus‘ mr) mzero — 
return a ‘mplus‘ (interleave mzero mr) — 
return a ‘mplus‘ mr - m 

The main use of interleave and »— is in avoiding divergence 
when composing computations with a possibly infinite number of 
answers. In finitary cases, interleave and »- are observationally 
equivalent to mplus and »= if the notion of observation does not 
include the order of elements in the final list of answers. More 
precisely, Hinze [11] interprets an equivalence a ^ b between 
monadic computations a and b to mean that runL Nothing a and 
runL Nothing b produce identical streams of answers (where the 
order of the answers is significant). In this paper, we always in¬ 
terpret the equivalence the same way. This is important when we 







later consider non-deterministic computations layered over arbi¬ 
trary monadic computations. In such cases the order of the non- 
deterministic answers must indeed be assumed to be observable. 

We should however mention in passing a different approach, 
which asserts that the order of answers should not be part of the 
observational semantics of non-deterministic computations. In that 
case, runL Nothing a and runL Nothing b need only return the 
same multiset of answers. Using this—weaker, less deterministic 
and more liberal notion of equivalence based on multisets—the 
laws of Definition 3.1 become an instance of the simpler laws of 
Definition 2.1. 

3.5 Soft cut (Conditional) 

In Haskell, one can use ordinary conditionals within a sequence of 
commands. While these constructs are quite useful, a logical condi¬ 
tional is still wanting. The conventional conditional constructs can 
easily express the situation when one computation depends on the 
success of another. For example, the non-deterministic computa¬ 
tion odds, which produces an odd number, can be “restricted” to 
only succeed when the odd number is divisible by another number: 
iota n = msum (map return [ I .. n \) 
test_oc = runL (Just 10) 

(do n <— odds 
guard (n > 1) 
d «- iota {n - 1) 
guard (d> 1 A n ‘mod‘ d = 0) 
return n) 

The result is [9,15,15,21,21,25,27,27,33,33], We use guard 
from the standard Monad library to filter out only those numbers 
generated by odds that are evenly divisible by some number d 
between 1 and n exclusive. (The presence of duplicates in the result 
will be discussed in the next section.) 

The existing constructs are of no help however if we want to 
restrict the computation odds by filtering those odd numbers that 
are not divisible by any d in the given range, i.e., to produce odd 
prime numbers. For this case, we need the common paradigm in 
logic programming of “negation as finite failure”, which performs 
a logical computation when some other computation fails. 

What is needed in this case is a special logical conditional 
operator that we call ifte. The operation ifte t th el should evaluate 
as follows. First the computation t is executed. If it succeeds with at 
least one result, the entire ifte computation is equivalent to t »= th. 
Otherwise, the entire computation becomes equivalent to el. 

The construct ifte is equivalent to Prolog’s soft-cut (*->) and 
Mercury’s if-then-else construct. A similar construct has been pro¬ 
posed for a Haskell logic monad [3]. The behaviour of this con¬ 
struct is given by the following laws. 

Definition 3.2 (Laws for ifte). 

ifte (return a) th el — th a 

ifte mzero th el - el 

ifte (return a ‘mplus‘ m ) th el — th a ‘mplus‘ (m »= th) 

The first two equivalences formalise the basic intuition of the con¬ 
struct. The third equivalence is more interesting: as soon as the test 
command succeeds once, the th branch is immediately executed 
and the el branch can never be tried. Thus: 

ifte (mi mplus m 2 i th el ¥ 

(ifte mi th el) ‘mplus‘ (ifte m 2 th el) 

In other words, the context ifte [] th el interacts in an unusual 
way with mplus. Because the el branch is only attempted when the 
test fails on the initial (rather than on a backtracking) try, ifte is 


particularly useful [4] for “explaining failure.” For example, the el 
branch may contain a computation that records (e.g., prints) the fact 
and circumstances of failure of that particular test, and thus helps 
avoid uninformative, silent failures. Another common application 
of soft-cut, mentioned by Andrew Bromage [4], is committing to 
a heuristic (expressed as the test of ifte) if the heuristics applies. 
Section 7 illustrates with such an application. 

Example 3.1. With ifte we can now modify the example at the be¬ 
ginning of the section to generate the odd prime numbers: 

test_op = runL (Just 10) 

(do n <— odds 
guard (n > 1) 
ifte (do d <- iota (n - 1) 

guard (d > 1 A n ‘mod‘ d = 0)) 
(const mzero) 

(return n)) 

The result is [3,5,7,11,13,17,19,23,29,31]. 

3.6 Pruning (Once) 

The operator ifte is in some sense a pruning primitive. Another 
important pruning primitive is once, which selects, generally non- 
deterministically, one solution out of possibly many. The operator 
once greatly improves efficiency as it can be used to avoid useless 
backtracking and therefore to dispose of data structures that hold 
information needed for backtracking (e.g., choice points). The once 
primitive is also important for expressiveness, as it expresses “don’t 
care non-determinism.” For example, without it, non-deterministic 
polynomial-time Datalog queries are inexpressible [9], 

Naish [18] suggests a simple example that motivates the use of 
once. The example is based on the following code, which shows 
how to sort a list by generating all permutations and testing them: 


bogosort l 

= do p <— permute l 

if sorted p then return p else mzero 

sorted (ei : e 2 : 

r) = e i ^ e 2 A sorted (e 2 : r) 

sorted _ 

= True 

permute [ ] 

= return [ ] 

permute (h : t) 

= do { t’ «— permute t; insert h f} 

insert e [ ] 

= return [e] 

insert el@(h: 

t) = return (e : T) ‘mplus ‘ 

do \ t’ <— insert e t; return (h : f')l 

Despite being 

a bit contrived, this example is characteristic 


of logic programming: generate candidate solutions and then test 
them. The function bogosort can have more than one answer in 
case the list to sort has duplicates. For example: 

runL Nothing (bogosort [5,0,3,4,0,1 ]) 
produces two answers that differ in the order of the first two el¬ 
ements: [[0,0,1,3,4,5], [0,0,1,3,4,5]]. Clearly this order is not 
observable, and we only need any one of the answers, which we 
can express by changing the definition of bogosort to be: 

bogosort' l = once (do p <— permute l 

if sorted p then return p else mzero) 
The change does not constrain the use of bogosort in a larger 
program which itself uses backtracking. It is just that bogosort 1 
avoids backtracking during the sorting itself because it is useless 
and wasteful. 

In more general situations, different solutions may not be equiv¬ 
alent, and yet we may be satisfied with any of them for the purposes 
of a particular application. For example, in model checking we are 



usually satisfied with the first counterexample. As another example, 
our test_op in Example 3.1, which computes odd prime numbers, 
calculates all the factors of a composite number, which is wasteful 
for primality testing. If any factor is found, the number is not prime, 
and there is no need to look for more factorisations. In other words, 
test_op could be modified as follows: 
test_op' = 
runL (Just 10) 

(do n <— odds 
guard (n > 1) 

ifte (once (do d <— iota (n - 1) 

guard (d> 1 A n ‘mod‘ d = 0))) 
(const mzero) 

(return n)) 

The use of ifte and once implements “negation as failure.” As 
Andrew Bromage explains [4], this pattern can be abstracted into 
the following construct: 

gnot :: (Monad m,LogicT I, Monad Plus (t m)) => 
t ma —> t m() 

gnot m = ifte (once m) (const mzero ) (return ()) 

Clearly, if m succeeds then gnot m fails, and if m fails then gnot m 
succeeds. Moreover, after the first time gnot m fails, there is no 
reason to backtrack into m; any more results it might produce will 
just be ignored. 

4. Splitting Computations 

Remarkably, the additional primitives in the more expressive in¬ 
terface presented in the previous section can all be implemented 
using one basic new abstraction msplit. We begin by formalising 
the extended interface as a Haskell type class that can be instanti¬ 
ated with one method: msplit. We give all the remaining operators 
default definitions. 

4.1 The Monad LogicM 

The class LogicM in Figure 1 formalises the interface discussed 
in the previous section. It includes the functions used there: 
interleave, »-, ifte, and once, with default implementations us¬ 
ing the function msplit. Conspicuously absent from the LogicM 
class is a function runL. It turns out that it can also be easily ex¬ 
pressed using msplit. We discuss that implementation for a more 
general case of a monad transformer LogicT in Section 6. 

Intuitively msplit takes a computation and determines if that 
computation fails or succeeds at least once. Operationally, we think 
of msplit as running its input computation looking for the first 
successful choice, providing a sort of “lookahead” of size one. The 
behaviour of msplit can be formalised using the following two laws. 

Definition 4. 1 (Laws for msplit). 

msplit mzero - return Nothing 

msplit (return a ‘mplus‘ m) ^ return (Just (a, m)) 

The first law formalises that a computation that fails cannot be split. 
The second law states that a computation that succeeds at least once 
can be split into the first result and the rest of the computation. 

Using the default implementations in LogicM we can verify the 
axioms for our primitives assuming msplit satisfies its axioms. For 
example, we can verify: 

ifte (return a) th el 
- do r «— msplit (return a) 
case r of 
Nothing —> el 

Just (sg ] ,sg 2 ) -> (th jgj) ‘mplus‘ (sg 2 »= th) 


class MonadPlus m => LogicM m where 
msplit :: m a —* m (Maybe (a, m a)) 

interleave :: m a —> m a —> m a 

interleave sg t sg 2 = 
do r <— msplit sg , 
case r of 
Nothing —* sg 2 
Just(sg n ,sg l2 ) -> 

(return sgn) ‘mplus‘ (interleave sg 2 sg 12 ) 

(»-): ■.:ma^(a^mb)^mb 

sg »- g 
do r «— msplit sg 
case r of 
Nothing —> mzero 

Just (sg\, sg 2 ) -> interleave (g sg,) (sg 2 »- g) 
ifte :: m a —* (a —* m b) —> m b —> m b 

ifte t th el = 

do r <— msplit t 
case r of 
Nothing —> el 

Just (sg u sg 2 ) -> (th sgi) ‘mplus‘ (sg 2 »= th) 



do r <— msplit m 
case r of 
Nothing —> mzero 
Just (s,^, _) —» return sg! 


Figure 1. The class LogicM 

& do r «— msplit (return a ‘mplus‘ mzero) 
case r of 
Nothing —> el 

Just (sg!,sg 2 ) -> (th sgi) ‘ mplus‘ (sg 2 »= th) 

£ do r <— return (Just (a, mzero)) 
case r of 
Nothing —> el 

Just (sgj,sg 2 ) -» (th sgj) ‘ mplus‘ (sg 2 »= th) 

^ case Just (a, mzero) of 
Nothing —» el 

Just (sgi,sg 2 ) -»(th sgi) ‘mplus‘ (sg 2 »= th) 

- (th a) ‘mplus‘ (mzero »= th) 

A tha 

4.2 Implementing msplit Using Lists 

The main technical challenge addressed in the paper is in imple¬ 
menting msplit in monads that use continuations. The implementa¬ 
tion of msplit in the case of the list monad is straightforward and 
provides some helpful intuition, 
newtype SSG a = Stream [a] 
unSSG (Stream str) = str 
instance Monad SSG where 
return e = Stream [e] 

(Stream es) »=/ = Stream (concat (map (unSSG of) es)) 
instance MonadPlus SSG where 

mzero = Stream [ ] 

(Stream es{) ‘mplus‘ (Stream esf) = Stream (esi -h- es 2 ) 



class MonadTrans t => LogicT t where 

msplit :: (Monad m,MonadPlus (t m )) => 

l m a —> t m (Maybe (a, t m a )) 
interleave :: (Monad m,MonadPlus (t m)) => 


(»-) :: (Monad m,MonadPlus it m)) => 

t m a —> (a t mb) ^ t mb 
ifte :: {Monad m, MonadPlus (t m)) => 

tma—>(a—>tmb)—>tmb—>tmb 
once :: (Monad m, MonadPlus (t m)) => 


Figure 2. The class LogicT 

instance LogicM SSG where 

msplit (Stream [ ]) = return Nothing 

msplit (Stream (h : t)) = return (Just ( h, Stream t )) 

The implementation is essentially the List monad that is already 
present in Haskell. As argued earlier, the reliance on the list monad 
has several drawbacks, many of which are discussed by Hinze [11]. 
In addition, the above implementation cannot be easily modified to 
become a monad transformer since List as a transformer can only 
be applied to commutative monads [12], 

4.3 The Monad Transformer LogicT 

Instead of working with the fixed monad LogicM, we would like to 
uniformly add msplit to other monads, thus augmenting arbitrary 
computations with our backtracking facilities. 

In Haskell, this can be achieved by using monad transformers. 
A monad transformer t is defined using a class: 

class MonadTrans t where 
lift:: Monad m => m a —»t m a 

Intuitively computations in a base monad m are lifted to computa¬ 
tions in a transformed monad t m. The lifting satisfies the following 

lift o return — return 

lift (m »= k) - lift m »= lift o k 

The specification of LogicM can be turned into a monad trans¬ 
former by simply copying the functions and giving them the re¬ 
quired generalised types. Indeed the interface to the class LogicT 
in Figure 2 is essentially identical to the one of LogicM\ for brevity 
we have not repeated the default implementations of the meth¬ 
ods. The precise relationship between the two figures is that the 
class LogicM can be recovered by applying the monad transformer 
LogicT to the identity monad. 

By inheriting from the library class MonadTrans, the class 
LogicT also includes the method lift that injects computations of 
the underlying monad of type m a into backtracking computations 
of type t m a. For example, lift (putStrLn "text") » mzero is a 
backtracking computation which performs a side-effect in the IO 
monad and then fails. 

The laws of msplit postulated in Definition 4.1 should be gen¬ 
eralised to handle the additional “lifted” effects from the under¬ 
lying monad [14]. In the first law, instead of considering a com¬ 
putation mzero, we should consider more generally a computation 
lift m » mzero which might perform computational effects in the 
underlying monad before failing. Similarly in the second law, in¬ 
stead of considering a computation return a ‘mplus‘ tm i, we should 
consider more generally a computation lift m ‘mplus‘ Inti which re¬ 
turns the first result after performing some arbitrary effects in the 


underlying monad. These generalisations are minimal and only de¬ 
scribe the morphisms that lift trivially. In some cases, a morphism m 
in the underlying monad may not be trivially lifted as lift m but 
rather as a new morphism tm that combines the backtracking ef¬ 
fects and underlying effects in non-trivial ways. This is similar to 
what happens when lifting callcc through the state monad trans¬ 
former for example [14], 

We motivate the new form of the laws by considering the gener¬ 
alised left-hand side of the second law: msplit (lift m ‘mplus‘ tm \). 
The computation tm\ has type tma whereas the result of msplit 
has the type t m (Maybe (a, t m a)), which makes relating these 
values inconvenient. Therefore, we define: 

reflect :: (Monad m, LogicT t, MonadPlus (t mi)) => 

Maybe (a,t m a) —>t m a 
reflect r = case r of 

Nothing —» mzero 

Just (a, tmr) —> return a ‘mplus‘ tmr 
rr tm = msplit tm »= reflect 

Now, rr tm has the same type as tm and hence the two can be more 
directly related. Direct inspection of the code of reflect shows that it 
introduces no effects at the source monad level and it does not affect 
the values of the monadic computation—the latter fact is obvious 
from the type, which is polymorphic over any a and any source 
monad m. We can now state the generalised laws. 

Definition 4.2 (Generalised Laws for msplit). 
rr (lift m » mzero) - lift m » mzero 
rr (lift m ‘mplus‘ tma) lift m ‘mplus‘ (rr tma) 

5. Implementations of LogicT 

We now focus our attention on the main technical challenge of the 
paper: the implementation of the LogicT monad transformer. We 
provide two implementations that manipulate continuations, either 
explicitly or implicitly using control operators. 

5.1 CPS Implementation 

The CPS-based implementation introduces the type constructor 
SFKT for functions accepting success and failure continuations. 
The answer type is fully polymorphic: 

newtype SFKT ma = 

SFKT (V ans. SK (m ans) a —» FK (m ans) -> m ans) 
unSFKT (SFKT a) =a 

type FK ans = ans 

type SK ans a =a^> FK ans -> ans 

The concrete type of monadic actions is SFKT m a, where m is the 
source monad to be transformed. 

The following instance declarations specify that SFKT m is a 
Monad and MonadPlus, and that SFKT is a monad transformer. 
These instance declarations are quite straightforward, and match 
the implementation of the monad transformer (without cut) given 
by Hinze [11], 

instance Monad m => Monad (SFKT m) where 
return e = SFKT (Ask fk —> sk efk) 

SFKT (Ask -> unSFKT m(Aa^> unSFKT (f a) sk)) 

instance Monad m => MonadPlus (SFKT m) where 
mzero = SFKT (A_fk -> fk) 

mi ‘mplus‘ m2 = 

SFKT (Askfk unSFKT mi sk (unSFKT m 2 skfk)) 



instance MonadTrans SFKT where 

lift m = SFKT (Ask fk -» m »= (Act -> sk afk)) 

As Hinze explains, this “context-passing” implementation im¬ 
proves on the naive term implementation by removing an interpre¬ 
tive layer. But in order to augment the above implementation with 
control over backtracking (e.g., cut), Hinze changes the represen¬ 
tation of contexts in order to pattern-match against them, restor¬ 
ing an interpretive layer. We show however that this is not neces¬ 
sary: we can maintain the abstract representation of continuations 
and support msplit. But indeed, contrary to the situation in Sec¬ 
tion 4.2 where we implement msplit using lists, the implementa¬ 
tion of msplit for the two-continuation monad transformer SFKT is 
more challenging: 

instance LogicT SFKT where 

msplit tma = lift (unSFKT tma ssk (return Nothing)) 
where ssk afk = return (Just (a, (liftfk »= reflect))) 
Intuitively, to split a computation tma, we supply it with two 
custom success and failure continuations. If the failure continuation 
is immediately invoked, we get lift ( return Nothing) which is essen¬ 
tially another way of expressing mzero in the transformed monad. 
If we encounter several non-deterministic choices and the success 
continuation is invoked in one of the cases with an answer a, we 
return this answer a and a suspension that can be used to continue 
the exploration of the other choices. This is reminiscent of the list 
implementation but works even if t m a for arbitrary m is generally 
not a recursive data type. 

Since the correctness of msplit is not so obvious, we outline a 
proof in the remainder of the section. The first law of msplit: 

rr (lift m » mzero) - lift m » mzero 

follows from the monadic laws, the definition of reflect and the 
observation: 

msplit (lift m » mzero) - lift m » (return Nothing), 
which can be derived from the code of the above instance declara¬ 
tions. To prove the second law of msplit: 

rr (lift m ‘mplus‘ tma) - lift m ‘mplus‘ (rr tma) 
we observe that: 

lift m ‘mplus‘ tma ss 

SFKT (Askfk -> (Askfk -> m »= (Aa -» sk afk)) 
sk 

(unSFKT tma skfk)) - 

SFKT (Askfk -> m »= (Aa -> sk a (unSFKT tma sk fk))) 
Thus we have: 

msplit (lift m ‘mplus‘ tma) - 

lift m »= (Aa —> return (Just (a, rr tma))) 

The desired result follows from the definition of rr and monadic 
laws in the m a and tma monads. 

Furthermore, if we define g f v tm = unSFKT (rr trn) f v we 
can easily obtain, from the definition of rr, that: 
gf v mzero * v 

g f v (lift m‘mplus‘tmi) as m »= (Aa -> f a (g f v tmj) 
that is, g is essentially fold, which clarifies the meaning of the 
function rr. 

5.2 Implementation Using Delimited Control 

The implementation based on control operators uses an exten¬ 
sion of the fully answer-type-polymorphic delimited continuation 
framework developed by Dybvig et. al. [7], The framework pro¬ 
vides two type constructors of interest: CC for computations that 


manipulate delimited continuations and Prompt for control delim¬ 
iters. We first extend the implementation to make CC a monad 
transformer and, using this extension, define the following small 
library of control operators: 
promptP : : Monad m => 

(Prompt r a —> CC r m a) —» CC rma 
abortP :: Monad m => 

Prompt r a —> CC r m a —> CC rmb 
shiftP :: Monad m => 

Prompt r b —» 

((CC rma^CCrmb)^CCrmb)^ 

CCrma 

The constructors Prompt and CC are parametrized by a type 
parameter r that refers to the control region associated with the 
computation. Intuitively a delimiter of type Prompt r a was created 
in a control region indexed by type r and its uses cannot escape 
from that control region. The type parameter r allows computations 
in the monad to be encapsulated using a construct of the following 
type: 

runCC :: Monad m => (V r. CC r m a) —> m a 
The control operators we implement above have the following in¬ 
tuitive explanation. The operator promptP creates a new delimiter, 
pushes it on the stack, and invokes its argument with access to the 
newly-pushed delimiter. The execution of the argument can later 
abort up to this occurrence of the prompt using abortP, or capture 
the continuation up to this occurrence of the prompt using shiftP. 
For example, in the following expression: 
runldentity (runCC (promptP $ Ap —> 

do x <— shiftP p (Ak —» k (k (return 2))) 
return (x + 1))) 

the evaluation proceeds by first creating a new prompt and pushing 
it on the stack. The evaluation of the do-expression then pushes the 
context do [x «— [ ]; return (x +1)1 on the stack before evaluating 
the shiftP expression. This expression captures the continuation up 
to the prompt p, reifies it as a function, and applies it twice to the 
argument 2. 

This instance of LogicT uses the CC library to define the type 
constructor SR as follows: 
newtype SR rma = 

SR (V ans. ReaderT (Prompt r (Tree r m ans)) (CC r m) a) 
unSR (SRf) =f 
data Tree r m a = HZero 
| HOnea 

| HChoice a (CC r m (Tree r m a)) 

At the core of the definition of the type SR r m a is a computa¬ 
tion of type CC rma that manipulates continuations using con¬ 
trol operators instead of having an explicit success and failure con¬ 
tinuation as in the previous section. The computation executes in 
the context of an environment implemented using ReaderT. The 
environment holds the most recently-pushed control delimiter, to 
which the computation should abort if it fails. Computations in the 
ReaderT monad transformer are executed using the library function 
runReaderT, and access the environment using the library function 
ask, which in our case has the type: 

ReaderT (Prompt r (Tree r m ans)) (CC r m) 

(Prompt r (Tree r m ans)). 

The SR r m monad is essentially the direct-style version of 
the two-continuation implementation in the previous section. Pre¬ 
viously, non-determinism was realized with the help of success and 




failure continuations. The success continuation receives not only 
the produced value but also a (failure) continuation to invoke if 
that value was “not good enough” (failure when processing that 
value). Here, the success continuation is represented by an implicit 
stack of pending computations with control delimiters marking the 
choice junctions. A non-deterministic choice is then represented by 
capturing the delimited continuation up to the closest delimiter and 
trying each of the branches using that continuation; failure is rep¬ 
resented by aborting the current delimited continuation. 

In the two-continuation model, there was no special way to 
represent deterministic computations, which produce exactly one 
value. In the current model, we find it useful to distinguish deter¬ 
ministic results from non-deterministic results by using the data 
type Tree r m a. A deterministic result is marked by tagging it with 
HOne. A failure is represented by HZero and a choice is represented 
by HChoice a r. The latter value describes both the result a of the 
performed computation and the not-yet-executed computation that 
represents the other part of the choice. It is possible to represent 
deterministic computations as HChoice a (return HZero ) at the 
expense of obscuring the definitions and losing some performance. 

The following definition shows that the type SR r m is an 
instance of Monad : 

instance Monad m => Monad (SR r m) where 
return e = SR (return e) 

(SR m) »=/ = SR (m »= (unSR of)) 

The definition shows that deterministic computations are executed 
“normally”—that is, as if they were in the base monad m. And since 
SR is a newtype, tagging with SR and untagging with unSR do not 
take any run time. 

We then show that SR r mis an instance of MonadPlus: 
instance Monad m => MonadPlus (SR r m) where 

SR (ask »= Apr —> lift (abortP pr (return HZero))) 

SR (ask »= Apr —> 

lift $ shiftP pr $ Ask —> 
do/i <— sk (runReaderT (unSR mi) pr) 
let/2 = sk (runReaderT (unSR mf) pr) 
composeJrees fi ff) 

composejtrees :: Monad m => 

Tree r m a —* 

CCrm (Tree r m a) 

CCrm (Tree r m a) 
composejtrees HZero r = r 

compose Jrees (HOne a) r = return $ HChoice a r 

compose Jrees (HChoice a r') r = 

return $ HChoice a $ r' »= (Av —> composejrees v r) 

A failing computation mzero simply aborts to the current delim¬ 
iter with the result HZero. A non-deterministic choice is slightly 
more complicated: we capture the continuation sk up to the current 
delimiter. The first alternative mi is immediately executed in that 
continuation; the second alternative m2 is suspended. The function 
composejrees builds a new Tree combining the results obtained 
from the first branch with the suspension from the second branch. 

Before discussing the implementation of msplit we discuss a 
necessary function used to implement msplit. This function reify 
represents the computational effect of backtracking in an algebraic 
data type as described in two recent papers [24, 13]: 

reify :: Monad m => SR r m a —> CC r m (Tree r m a) 
reify m = promptP (Apr —» runReaderT (unSR m) pr »= 
(return o HOne)) 


As the code shows, the function reify m creates a new prompt, sets 
it, executes the computation, and tags the result with HOne. If the 
computation m executes deterministically, we get the result HOne a 
where a is the resulting value. If the computation m fails, then the 
continuation (return o HOne) is aborted and we instead get HZero 
as the resulting value. Finally, let us dlustrate the case where the 
computation m is about to execute mplus m\ m2 using the following 
example: 

reify (mo »= (Ax —> kl x ‘mplus‘ k2 x) »= k3) 
where m0 is deterministic. This example is equivalent to: 

do HOne x <— reify mo 

flval reify (kl x »= k3) 
let f2comp = reify (k2 x »= k3) 
composejrees flval f2comp 

Her e flval is the result (reified into the Tree data type) of the first 
choice of mplus, and f2comp is the computation that corresponds to 
the second choice. If flval is HZero —that is, the first choice even¬ 
tually fails (either in kl or in k3), then composejrees will run the 
computation f2comp and the (reified) result of the latter shall be the 
result of the original computation. In other words, if the first choice 
fails, we execute the other one. If the first choice finishes deter¬ 
ministically, i.e., if flval is HOne a, then composejrees represents 
the available choice by creating a result HChoice a f2comp, which 
suspends the computation f2comp to be later explored if needed as 
a possible alternative solution. Finally, if flval is itself the choice 
Choice a r' —that is, the execution kl x »= k3 has (unexplored) al¬ 
ternative branches (represented by r'), the function composejrees 
essentially composes the unexplored choices r' with the unexplored 
choice f2comp. One may think of that “composition” as a rotation 
of a binary decision tree, or joining a branch f2comp to a binary 

It helps to contrast our way of handling non-determinism with 
the regular Prolog approach, epitomized in the Warren Abstract 
Machine (WAM). The WAM includes a stack, which contains both 
environments and choice points [22]. The stack of the WAM is 
represented by the regular execution stack of the Haskell system. 
In the above example, f2comp (or more generally the computation 
sk (runReaderT (unSR mf) pr) in the implementation of mplus) 
represents the choice point. The function composejrees essentially 
handles the “top-most” choice point (the CP register of the WAM). 

Our function composejrees opens up more flexible policies of 
handling the choice points. For example, once composejrees de¬ 
termines that flval is HZero (that is, represents failure), it may 
not run f2comp. Rather, it may tag f2comp with a special tag 
like Incomplete and return that. When one mplus is nested in an¬ 
other, the outer instances of composejrees, having received the 
Incomplete f2comp, may then decide, either to run that f2comp, 
or to try other choices, if any. Thus we can implement alterna¬ 
tive evaluation policies that avoid divergence in situations like 
(odds » mzero) ‘mplus ‘ m, that is, when disjoining (on the left) 
a computation that diverges on backtracking. 

Finally we implement msplit for the monad transformer SR r: 

instance MonadTrans (SR r) where 
lift m = SR (lift (lift m)) 

instance LogicT (SR r) where 

msplit m = SR (lift (reify m »= (return o reflect _sr))) 
where reflect jr HZero = Nothing 

reflect jr (HOne a) = Just (a, mzero) 
reflect jr (HChoice a n) = 

Just (a, SR (lift r t ) »= 

(return o reflect_sr) »= 
reflect) 



This implementation of msplit is more complicated than the 
CPS-based one because it must maintain the proper polymorphism 
of the answer type by not letting the type variable ans escape. 
Given the computation m, we first reify it. This will tell us if 
the computation fails, completes deterministically, or completes 
with one answer and the choice of an alternative solution. This 
is precisely the information that we need to know for msplit. The 
problem with the msplit implementation is that r, in HChoice a r, 
has the type CC r m (Tree r m a) (of the reified computation), 
whereas msplit must produce SR r m a. Thus we must be able 
to go from the reified computation Tree r m a “hack” to the 
computation m a. The recursion in the implementation of msplit 
accomplishes that goal: of reflecting a value HChoice a r back 
into the computation return a ‘mplus‘ r. The recursion of reflect_sr 
is a consequence of the fact that Tree r m a is a recursive data 
type (although SR r m a is generally not, depending on m). Note 
that msplit invokes reify, which sets the prompt, overriding the 
prompt set by the top-level reify. This “dynamic scoping” inherent 
in delimited control [2] is essential for msplit. 

In summary, we have implemented the LogicT interface to sup¬ 
port “direct-style” programming with a rich combination of several 
computational effects: of the base monad m, the computational of 
the CC monad, and of the Reader monad. Although the present 
SR r m a implementation may have a large cost because of the 
layering of several effects and because of the inherent cost of the 
CC monad, it is still worth using, at least for prototyping. Often 
“direct-style” implementations are clearer and lend themselves to 
deeper insights. Even though the SFKT monad seems more effi¬ 
cient (and we would recommend using it in production, because 
all its costs are quantifiable and not large), SR r m a seems to be 
better suited for prototyping of various choice-point selection poli¬ 
cies and other advanced implementations (suspensions, constraint- 
propagation, etc.) of logical programming systems. 

6. Running Computations 

We now implement runL, to run the backtracking monad and ob¬ 
serve its results as a list of answers. The simplest solution is to 
define the function solve for a particular monad, e.g., SFKT : 

solve :: (Monad m) =s SFKT m a —> m [a] 

solve (SFKT m) = 

m (Aafk —> fk »= (return o (a:))) (return [ ]) 
which is identical to the one provided by Hinze [11], This function 
runs the backtracking computation of type SFKT m a and collects 
all the answers in a fist (to be observed in the source m monad). 
One may think that this function is sufficient: to observe at most n 
answers, we need to examine the prefix of the resulting list of 
at most that size. The rest of the answers will not be produced. 
However, the latter is only true if the source monad m is non-strict. 
If however m is strict {e.g., IO), it is clear from the definition of 
solve that all the answers of SFKT m a will be produced and 
collected into the list, even if we need only a few of them. This 
also means that applying solve to a computation SFKT IO a that 
has an infinite number of answers (such as odds) will diverge. 

Thus we need a more general function runL, to which we can 
pass the maximum number of answers we wish to observe. That 
function will run the backtracking computation to the extent needed 
to observe that many answers, no more. Therefore, runL can be 
safely used with non-deterministic computations with an infinite 
number of answers over a strict monad. 

Implementing runL for the SFKT monad however appears to 
be all but impossible. To run a computation, we need to pass it a 
success and failure continuation. The success continuation receives 
one answer and a computation fk to run to get more answers. We 
can easily disregard the failure computation after the first answer: 


observe :: Monad m => SFKT m a —> m a 

observe {SFKT m) = 

m {Aafk —> return a) (fail "no answer") 

Or we can run that /1; computation after the first answer, as in solve, 
which gives us all answers. There does not seem to be a way to 
run fk only a certain number of times, as the interface of SFKT 
does not let us pass any counter from one invocation of the success 
continuation to the next. 

Here again msplit helps. It turns out that we can implement 
runL —moreover, we can implement a more general operation 
bagofN and even unfold. Furthermore, we can implement bagofN 
in a way that does not depend on the implementation of the back¬ 
tracking monad transformer. The operation bagofN is similar to 
Prolog’s bagof iterator. The latter collects all answers of a given 
goal in a fist. Our bagofN is more general, as it lets the user spec¬ 
ify the maximum number of answers wanted. This more general 
bagofN is not expressible in Prolog using bagof or other prim¬ 
itives, without resorting to destructive operations on the Prolog 
database: 

bagofN :: (Monad m, LogicT t,MonadPlus (t m)) => 

Maybe Int —>t m a —> t m [a] 
bagofN ( Just n) _ \ n f 0 = return [ ] 
bagofN n m = msplit m »= bagofN' 

where bagofN' Nothing = return [ ] 
bagofN' (Just (a, m')) = 

bagofN (finap pred n) m' »= (return o (a:)) 

If the first argument to bagofN is Just n, it selects at most n 
answers. Again, the operation msplit let us treat the backtracking 
monad as if it were a stream, regardless of its actual implemen¬ 
tation. The partially-applied bagofN Nothing is equivalent to the 
function sols of Hinze [11]. But there is no equivalent there of the 
more challenging and more expressive bagofN (Just n). 

The result type of bagofN is t m [a]: we are still in the trans¬ 
formed monad. To get back to the source monad m, we need to 
“observe” [11] the produced list value. The observation function is 
necessarily specific to the backtracking implementation. 2 For the 
SFKT monad, it is given above. For the SR monad, it is as follows: 

observe sr :: Monad m => (V r. SR r m a) —* m a 
observe sr m = runCC (reify m »= pickl) 

where pickl HZero =fail "no answer" 

pickl (HOne a) = return a 
pickl (HChoice a r) = return a 

Here, we reify the computation m into Tree r m a, then pick the 
first answer from the Tree, disregarding any other choices. 

With the help of observe we can now write the function runL 
that we have used to run our examples: 

type L a = V r. SR r Identity a 

runL :: Maybe Int —» La —> [a] 

runL nm = runldentity (observe sr (bagofN n m)) 

We also reveal the type of the backtracking monad L that we 
introduced in 3.1. For our examples, the type is the transformer 
SR r over the identity monad. The examples also run with the SFKT 
transformer. 

As an example of using the backtracking transformer over a 
non-trivial (and strict!) monad, we modify Example 3.1 to print 
all the factors that are produced: 


2 Ideally, the function observe should be part of the LogicT class, but this is 
not possible because of the universally quantified type variable r in the last 
implementation. 



testjopio = print =« observe (bagofN (Just 10) 

(do n <— odds 
guard (n > 1) 
ifte (do d ^ iota (n - I) 

guard (d> 1 A n ‘mod‘ d = 0) 
liftIO (print d)) 

(const mzero) 

(return n») 

The source IO monad lets us print out the intermediate results. This 
approach is far more robust than using Debug.Trace, as the output 
of the latter is hard to predict. The comparison with Example 3.1 
demonstrates the advantage of having a monad transformer, the 
bulk of the code of Example 3.1 remains the same. We merely add 
liftIO (print d) and the printing of the final result. 

7. A Larger Example: Tic Tac Toe 

Tic Tac Toe, Reversi and many other strategic boardgames are good 
examples of heuristic search. The Tic Tac Toe code, suggested by 
Andrew Bromage on the Haskell mailing list [4], illustrates many 
features of our monad transformer LogicT in conducting basic 
minimax search coupled with two heuristics. The present code is 
a generalisation of that by Andrew Bromage: It solves instances of 
the problem with boards of size n x n and where m consecutive 
marks are required for a win (such as Gomoku). We also added 
explicit limits on the depth and breadth of the search. Without the 
limits, the program is too slow for interactive play on boards larger 
than 3x3. The code accompanying the article includes the complete 
program. 

We begin by declaring the basic types for representing the board 
and the marks: 

data Mark = X \ O deriving (Ord , Eq, Show ) 
type Loc = ( Int , Ini) 
type Board = FiniteMap Loc Mark 
data Game = Game(winner :: Maybe (Loc,Mark), 
moves :: [Loc], 
board :: Board) 

The type Loc describes (row, column ) coordinates of one board 
cell, as a pair of integers within [0.. n - 1 ]. A finite map Board 
maps the coordinates of marked locations to their marks. We use 
type Mark to identify players as well. The current state of the game 
is a record of the current board position, the list of available moves 
(i.e., unmarked cells) and the indicator of the winner. 

The function 
new'game :: Game 
initialises the board. The function 

take'move :: Mark —» Loc —> Game —> Game 
take'move p loc g = 

Game{moves = delete loc (moves g), 
board = board', 

winner = let (n, 1) = max' cluster board' p loc 

in if n ^ m then Just ( l,p ) else Nothing] 
where board' = addToFM (board g) loc p 
accounts for a move (i.e., the placement of a mark on a previ¬ 
ously empty cell) and generates the new game state. The function 
max'cluster :: Board —> Mark —» Loc —> (Int, Loc) computes the 
number of consecutive marks of the same sort around a given loca¬ 
tion, maximized over all possible directions. 

Let us define the player procedure that takes the player’s mark, 
the game state, and, non-deterministically, makes a move and re¬ 
turns the new game state together with an estimate of the game 
score for the player. 


type PlayerProc 1 (m ::*—>*) = 

Mark —> Game —> t m (Int, Game) 

The main game function can then be defined: 

game :: (MonadPlus (t m), LogicT t. 

Monad m, MonadIO (t m)) => 

(Mark, PlayerProc t m) —> 

(Mark, PlayerProc t m) —> 
tm() 

game playerl player2 = game' playerl player2 new'game 
where game' player@(p,proc) other 1 player g 
| Game[winner = Just k ]«— g 

= liftIO (putStrLn ((show k) -h- " wins! ")) 

| Game[moves = []}«— g 
= liftIO (putStrLn "Draw! ") 

| otherwise 

= do (_, g') «- once (proc p g) 

liftIO (putStrLn $ show’board (board g')) 
game' other 1 player player g' 

The expression once (proc p g) means that once the player has 
made the move, the move is committed and cannot be un-played. 

Our playing strategy is the basic minimax search. We first check 
if we reached the terminal, goal state. 

ax' :: (MonadPlus (t m). Monad m, LogicT t) => 

PlayerProc t m 
ai' pg = ai'lim m6pg 
where ai'lim dlim blim p g 

| Game[winner = Just _} «— g 
= return (estimate'state p g, g) 

| Game[moves = [])<— g 

= return (estimate'state p g, g) 

| otherwise 

= minmax ai'lim dlim blim p g 

If not, we pick such a successor state that minimizes the score for 
our opponent assuming the opponent always makes its best move: 

minmax :: (MonadPlus (t m). Monad m, LogicT t) => 

(Int —> Int —> PlayerProc t m) —> 

(Int —> Int —> PlayerProc t m) 
minmax self dlim blim p g = 
do wbs <— bagofN (Just blim) 

(do m <— choose (moves g) 
let g' = take'move p m g 
if dlim d 0 

then return (estimate'state p g',g') 
else do (w, ) <— self (dlim - 1) blim 
(other 1 player p) g' 
return (-w,g')) 

return (maximumBy (A(x, ) (y, ) —> compare x y) wbs) 

The number dlim limits the depth of the search and the number 
blim limits the number of moves considered at each step. The 
function choose non-deterministically chooses one move out of all 
available, and the function estimate'state :: Mark —> Game —> Int 
estimates the game score for the given player, as a signed integer 
in [-score'win.. score'win ]. The larger the integer, the better the 
position. We see the application of bagofN operation of LogicT. 

Unfortunately, this code is too slow. Even for such a simple 
game on a 3 x 3 board, the search space is noticeably large. Andrew 
Bromage has pointed out two safe heuristics. They are based on 
the following function, which determines if there is a move that 
immediately leads to victory for the player p: 



first'move'wins p g = 

do m «— choose (moves g) 
let g' = take'move pm g 

guard (maybe False (A(_,p') —> p' = p) (winner g')) 
return (m, (score'win, g')) 

We can change our play function as follows: 
ai':: (MonadPlus (t m). Monad m,LogicT t) => 

PlayerProc t m 
ai’ p g = ai'lim m 6 p g 
where 

ai'lim dlim blim p g 

| Game{winner = Just _) <— g 
= return (estimate'state p g, g) 

| Game[moves = []) <- g 

= return (estimate'state p g, g) 

| otherwise 

= ifte (once (first 1 move'wins p g)) 

(return o snd) 

(ifte (once (first 1 move’wins (othePplayer p ) g)) 
(A(m, _) —> do let g’ = take'move p m g 
(w, _) <— ai'lim dlim blim 

(other'player p) g’ 
return (-w, g')) 

(minmax ai'lim dlim blim p g)) 

If there is a winning move, we take it, without further ado. We 
are only interested in one such move, hence once. If we cannot 
immediately win but our opponent can on the next move, we block 
that move. The ifte forms signify the commitment to a heuristic 
once it applies. If, and only if, none applies, we do the minimax 
search. To let the computer play against itself, we run the following 
computation: 

allal :: 10 () = observe % game ( X,ai ') (0,ai') 

The complete code also includes a function for a human player, 
so one can play against the computer. Although currently the choice 
and scoring functions are simplistic, and the search limits are low, 
the play is good enough to be entertaining. 

8. Related Work 

Seres and Spivey [23] explored fair conjunction, but their imple¬ 
mentation relied exclusively on streams, instead of being purely 
monadic with operators »- and interleave. Our solution not only 
handles the stream representation but at least two other represen¬ 
tations, Federhen’s two-continuation model [8] and the “control 
channel.” Wand and Vaillancourt [31] formally related the stream 
and two-continuation semantics of backtracking, but they did not 
consider more general monadic streams or splitting of the back¬ 
tracking computation. 

Hinze [11] described backtracking transformers that support 
non-deterministic choice, and limited-extent Prolog-like cut. His 
final, efficient context-passing implementation was explicitly not 
continuation-passing because it required pattern-matching on the 
context. In addition, he ignored the problem of managing termina¬ 
tion, which we address with interleave and »-. Furthermore, we 
added the ability to select any given number of answers. This is of 
course easy using streams, but difficult in the two-continuation and 
“control-channel” solutions; we believe that we are the first to im¬ 
plement these monadically. One weakness of our approach as com¬ 
pared to Hinze’s is that he shows how to derive the transformers, 
with the promise of mechanization. That promise is not completely 
fulfilled however when cut is involved. Our approach is akin to the 
one he contrasts with in his introduction: “Because it works.” 


CPS-based implementations of Prolog with cut were discussed 
by de Bruin and de Vink [6], who used three continuations, for 
success, failure, and cut. In this paper, we have shown a CPS-based 
system with negation and Prolog-like pruning that uses only two 
continuations. 

9. Conclusion 

We have introduced a backtracking monad transformer, which, in 
addition to the MonadPlus interface, provides fair conjunctions 
and disjunctions, logical conditional and pruning (don’t-care non¬ 
determinism), and selecting an arbitrary number of answers. We 
have described two implementations of the transformer, a CPS one 
with two continuations, and a direct-style one based on a Haskell 
library of delimited continuations [7]. All additional backtracking 
operations are implemented generically, in terms of one operation 
msplit. 

Our msplit operation lets us treat the backtracking transformed 
monad as if it were a stream—even when the monad is not a 
stream and not even of a recursive type (which is the case for both 
our implementations). We can therefore observe not just the first 
solution from a backtracking computation but an arbitrary number 
of solutions. 

In future research, we plan on using our direct-style implemen¬ 
tation to implement sophisticated backtracking policies that can 
handle, for example, left recursion without tabling. 
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